According to the seven-layer Open Systems Interconnection model, more commonly referred to as the OSI model, the MAC data communication protocol is found in the second layer above the Physical Layer or PHY. The MAC layer is a sublayer of the Data Link Layer interacting directly with the PHY layer.
While the PHY layer defines in which way bits and bytes are transmitted over a specific medium, the MAC layer defines how frames are formatted with these bits and bytes and how and when the frames are to be communicated over the transmission medium towards other terminals in an optimized way, i.e. guaranteeing the best possible performance in terms of throughput, latency, quality of service or other performance metrics.
A MAC layer protocol may be usable for different PHY layer protocols. One example here is the IEEE 802.11 protocol offering wireless access over a variety of transmission mediums and thus PHY protocols. Depending on the application requirements of the communication network, different MAC layer protocols may also be implemented on top of a single PHY layer. For example, in the IEEE 802.15.4e standard multiple MAC techniques such as time slotting, channel hopping, asynchronous multi-channel adaptation, multi-super frames and slot frames are proposed to support a wide range of industrial and commercial applications. As a result, the MAC is a complex algorithm with stringent timing constraints that must execute radio actions, i.e. actions requiring access to the PHY layer, in a time accurate and time critical manner.
Due to the variety of MAC techniques and protocols, even for a single PHY, it is desirable to be able to implement new MAC techniques on top of existing hardware and software platforms. However, this is not always an easy task in existing solutions. In a lot of cases, MAC specific functions are integrated in hardware drivers interacting with the PHY layer in the radio interface in order to meet the critical timing requirements. For example in the 802.11 MAC specification, timings to be met are in the order of microseconds. Therefore, in order to implement new MAC functionality, new drivers must be developed and recompiled which is a complex and time consuming task. Also, as MAC specific code is often mixed with PHY specific code, part of the PHY may need to be re-implemented in order to change the functionality of the MAC layer. Moreover, as drivers typically run as kernel level modules on a processor or embedded processor, it is not straightforward to change MAC functionality or a MAC protocol at run-time without interrupting the system or rebooting the system.
Therefore, it would be desirable to be able to change time critical MAC functionality at run-time without the need for new or adapted drivers that interact with the PHY layer and thus the radio interface.
Several solutions have been proposed to overcome one or more of the above shortcomings. In the domain of Wireless Sensor Networks or WSN, the publication by J. Hauer, TKN15.4: An IEEE 802.15.4 MAC Implementation for TinyOS 2, Technical Report, 2009 presents a platform independent MAC for TinyOS, an operating system often used in wireless sensor platforms. However, parts of the MAC are still implemented in PHY specific drivers and, therefore, their conclusion is that “these [timing] requirements can practically not be met by a platform independent MAC protocol, rather they should be pushed from the MAC to the PHY, ideally to the hardware”. Therefore, the time critical MAC logic, sometimes referred to as the Lower MAC or L-MAC, is still platform specific and embedded in PHY specific drivers. As a result, the L-MAC implementation can only be changed by redeveloping drivers and recompiling them into new firmware for the TinyOS operating system.
Another solution in the WSN domain is proposed by R. Steiner, T. Mück, A. Fröhlich in “C-mac: A configurable medium access control protocol for sensor networks, Sensors, 2010 IEEE, pp. 845-848” where a generalized state machine for three major MAC categories is presented, i.e. for channel polling, scheduled contention and time division multiple access. The disadvantage of this solution is that it does not foster the creation of completely new MAC protocols. Moreover, the state machine does not allow fine-grained, time-accurate control of the radio functions as delays are in the order of milliseconds whereas time critical MAC control functions require maximum delays in the order of microseconds. A further disadvantage is that recompilation is needed for every reconfiguration of the MAC protocol.
In the Wireless Local Area Network or WLAN domain, the publication by I. Tinnirello, G. Bianchi, P. Gallo, D. Garlisi, F. Giuliano, F. Gringoli: “Wireless mac processors: Programming mac protocols on commodity hardware”, INFOCOM, 2012 Proceedings IEEE, pp. 1269-1277 introduced a programmable wireless platform called Wireless MAC Processors or WMP supporting a MAC defined in terms of a Finite State Machine (FSM). This FSM consists of transitions between states. These transitions can be triggered by events, e.g. a frame is received. The transition will be executed if a certain boolean condition is TRUE, e.g. sending of an acknowledgement or ACK. Before completing the transition to the new state, an action, e.g. the transmission of such an ACK, can be performed. A disadvantage of this solution is that it is impossible to adapt a MAC protocol, i.e. the FSM, at run-time locally on the network interface card. In WMP, an adapted MAC protocol and thus new FSM needs to be recompiled on a remote machine and re-injected in the network interface card.
It is an object of the present invention to obviate the above disadvantages and to provide a way to define MAC control logic—and Lower MAC control logic in particular—that is replaceable at run-time and does not require a recompilation nor a redevelopment of drivers because part of the logic is embedded in these drivers.